Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

MDEV-35081 - Assertion `!n_mysql_tables_in_use' failed after error up… #3798

Open
wants to merge 1 commit into
base: 11.7
Choose a base branch
from
Open

MDEV-35081 - Assertion `!n_mysql_tables_in_use' failed after error up… #3798

wants to merge 1 commit into from
+25 −1

Conversation

svoj
Copy link
Contributor

@svoj svoj commented Jan 28, 2025

  • The Jira issue number for this PR is: MDEV-35081

Description

…on binary logging of DML involving vector table

InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED. This limitation is enforced by a check within ha_innobase::external_lock().

InnoDB also expects number of "successful external locks" to match number of "external unlocks", which is controlled by the assertion in subject.

However "unlock" was called even after failing "lock" for high-level indexes.

Fixed by calling "unlock" only after "successful lock".

Release Notes

N/A

How can this PR be tested?

mtr binlog_innodb_stm

Basing the PR against the correct MariaDB version

  • [] This is a new feature or a refactoring, and the PR is based against the main branch.
  • This is a bug fix, and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

  • I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
  • For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

@svoj
MDEV-35081 - Assertion `!n_mysql_tables_in_use' failed after error up…
baafccf 
…on binary logging of DML involving vector table

InnoDB is limited to row-logging when transaction isolation level is
READ COMMITTED or READ UNCOMMITTED. This limitation is enforced by
a check within ha_innobase::external_lock().

InnoDB also expects number of "successful external locks" to match
number of "external unlocks", which is controlled by the assertion
in subject.

However "unlock" was called even after failing "lock" for high-level
indexes.

Fixed by calling "unlock" only after "successful lock".
@svoj svoj requested a review from vuvova January 28, 2025 20:47
@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@svoj
Copy link
Contributor Author

svoj commented Jan 28, 2025

@vuvova please note that #3631 as it is now may solve this particular issue as well, but it won't solve case when hlindex lock fails, but table lock itself succeeds.

@svoj
Copy link
Contributor Author

svoj commented Jan 29, 2025

@vuvova thinking more on this... you mentioned once that hlindex has to be locked after the table. But in this case it is locked before:
Sql_cmd_dml::execute / Sql_cmd_dml::prepare / Sql_cmd_update::prepare_inner / JOIN::prepare / multi_update::prepare / handler::prepare_for_modify / TABLE::open_hlindexes_for_write / TABLE::hlindex_lock / handler::ha_external_lock

The table itself is locked later:
Sql_cmd_dml::execute / lock_tables / ...

It can happen so that this is the real problem rather than what I try to solve here.

@cvicentiu cvicentiu added the MariaDB Foundation Pull requests created by MariaDB Foundation label Jan 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@vuvova vuvova Awaiting requested review from vuvova

Assignees
No one assigned
Labels
MariaDB Foundation Pull requests created by MariaDB Foundation
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@svoj @CLAassistant @cvicentiu